SQLiteは軽量で柔軟なRDBですが、正規化・非正規化の判断を誤ると性能劣化や保守性低下につながります。 特に業務アプリでは、速度・整合性・実装コストのバランスが重要です。
この記事でわかること
・正規化の基本（第1〜第3正規形）
・SQLite特有の事情（制約の緩さ・JOINコスト）
・非正規化のメリット・デメリット
・実務での判断基準（いつ正規化し、いつ非正規化するか）
・業務アプリ向けベストプラクティス
・正規化の基本（第1〜第3正規形）
・SQLite特有の事情（制約の緩さ・JOINコスト）
・非正規化のメリット・デメリット
・実務での判断基準（いつ正規化し、いつ非正規化するか）
・業務アプリ向けベストプラクティス
1. 正規化とは？（第1〜第3正規形）
正規化は、データの重複を排除し、整合性を保つための設計手法です。
■ 第1正規形（1NF）
- 繰り返しの値を持たない
- 1セルに1値
■ 第2正規形（2NF）
- 主キーの一部に依存する列を排除
■ 第3正規形（3NF）
- 非キー属性が他の非キー属性に依存しない
業務アプリでは第3正規形まで満たせば十分です。
2. SQLite特有の事情（正規化しすぎると遅くなる）
SQLiteは軽量なため、 JOINが多いと一気に遅くなるという特徴があります。
■ SQLiteのJOINコスト
- インデックスが無いと致命的に遅い
- 複雑なJOINはメモリ消費が増える
- 大量データのJOINは特に重い
注意：
「正規化すれば正しい」ではなく、
SQLiteでは正規化しすぎると逆に遅くなることがある。
3. 非正規化とは？（あえて重複を許す設計）
非正規化は、パフォーマンス向上のために あえてデータを重複させる設計手法です。
■ 非正規化のメリット
- JOINが減る → 高速化
- 検索がシンプルになる
- SQLiteの弱点（JOIN性能）を補える
■ 非正規化のデメリット
- 更新時に複数箇所を変更する必要がある
- 整合性が崩れるリスク
4. 実務でよくある判断基準
■ 正規化すべきケース
- マスタデータ（顧客・商品・社員など）
- 更新頻度が高いデータ
- 整合性が重要なデータ
■ 非正規化すべきケース
- 検索画面でJOINが多くて遅い
- 大量データをDataGridに表示する
- レポート・集計用のテーブル
- 履歴データ（更新しない）
5. 非正規化の実例（SQLite向け）
■ 例：注文テーブルに顧客名を持たせる
正規化された構造：
Customers(Id, Name)
Orders(Id, CustomerId, Amount)
非正規化：
Orders(Id, CustomerId, CustomerName, Amount)
■ メリット
- JOIN不要 → 検索が高速
- DataGrid表示が速い
■ デメリット
- 顧客名変更時にOrdersも更新が必要
SQLiteではこの非正規化が非常に効果的。
6. SQLiteで正規化しすぎると起きる問題
- JOINが多くなり検索が遅い
- DataGrid表示が重くなる
- インデックスが複雑化する
- SQLが読みにくくなる
結論：
SQLiteは「正規化しすぎない」ことが実務では重要。
7. 正規化と非正規化のハイブリッド戦略
実務で最も安定するのはハイブリッド設計です。
■ ハイブリッドの例
- マスタは正規化（整合性重視）
- トランザクションは非正規化（速度重視）
- 集計・検索用に専用テーブルを作る
■ 検索専用テーブル（Materialized View的なもの）
OrdersSearch(Id, CustomerName, Amount, Date)
更新時に同期すればOK。
8. 業務アプリ向けベストプラクティス
- SQLiteはJOINが弱い → 正規化しすぎない
- 検索画面は非正規化テーブルで高速化
- マスタは正規化して整合性を保つ
- 更新頻度が低いデータは非正規化が有効
- DataGrid表示はJOINを避ける
- 必要なら検索専用テーブルを作る
まとめ：SQLiteの設計は“正規化しすぎない”が正解
- 正規化は整合性のため
- 非正規化は速度のため
- SQLiteはJOINが弱い → 非正規化が効果的
- 最適解はハイブリッド設計
「正規化すれば正しい」ではなく、 「SQLiteに最適なバランスを取る」のが実務の設計です。 この記事をベースに、あなたのアプリに最適なDB設計を構築してみてください。